Connecting Remote Systems for 
Demonstration of Automation Technologies 


R. M. Brown and R. Yee 

Systems Autonomy Demonstration Project Office 
NASA/Ames Research Center 
Moffett Field, CA 


ABSTRACT 


Work will begin this year on the development of the second 
of four demonstrations of automation technology under the Systems 
Autonomy Demonstration Project (SADP) . This demonstration will 
involve elements of four NASA Centers: ARC, JSC, LeRC, and MSFC. 
Intercenter digital data communications will be a vital element 
of this demo. 

This paper presents an initial estimate of the communica- 
tions requirements of the SADP development and demonstration 
environments, a proposed network paradigm is developed, and 
options for network topologies are explored. 


INTRODUCTION 


The Systems Autonomy Demonstration Project (SADP) was 
established to conduct a series of demonstrations of the use of 
advanced automation technology in solving problems applicable to 
the Space Station. The first demonstration, scheduled for 1988, 
will use expert system technology and model-based reasoning to 
monitor and control the operation of Johnson Space Center's 
Thermal Test Bed. 

Work will begin this year on the second SADP demonstration, 
this one scheduled for completion in 1990. Unlike the 1988 
demonstration, intercenter digital data communications will be a 
vital element of the 1990 demo. To accomplish the 1990 demo, 
elements of Lewis Research Center (LeRC) and Marshall Space 
Flight Center (MSFC) will be included in the SADP. The demon- 
stration itself requires the interaction of systems located at 
LeRC and JSC, and cannot be accomplished without intercenter data 
communications . 

Within NASA, intercenter data communications are provided 
through the Program Support Communications Network (PSCN) . The 
PSCN employs terrestrial and satellite transmission facilities to 
support all elements of the agency and provides a wide variety of 
services, including intercenter telephone, FAX, voice and video 
teleconferencing, electronic mail, and digital data communica- 
tions. The PSCN is based on a foundation of equipment and leased 
lines tying together all sixteen major NASA locations. 
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SADPNET REQUIREMENTS 


In designing a network like SADPnet, the first step is to 
define the overall network goals, including functions, connectiv- 
tivity , interfaces, operational quality and cost, expansion 
capability, and implementation cost. 

Hardware capabilities 

To understand the limits posed by the systems at each site, 
a study was made of the file transfer capabilities between a 
Symbolics 3600 system and two other computers on a 10-Mbit/sec 
Ethernet LAN. These measurements were made using the TCP-IP 
protocol and FTP service. The results are shown in Table 1. 


Table 1 — Measured file transfer rates 


Path 


No of 

File size 



trials 

(bytes) 

1 -> 

2 

7 

0 

1 <- 

2 

6 

0 

1 -> 

2 

10 

1210 

1 -> 

2 

5 

1209 KB 

1 -> 

3 

1 

1209 KB 


Av time 

variance 

transfer 

(sec) 

(sec) 

rate 

(bytes/sec) 

0.780 

0.003 

n/a 

2.345 

0.738 

n/a 

1.165 

0.010 

1039 

214.1 

10.2 

5647 

111.0 

0.0 

10892 


System 1 is a Symbolics 3600 running Genera 7.1 
System 2 is a DEC microVAX II running Ultrix 2.0-12 
System 3 is a DEC VAX 11/780 running VMS 4.5 


It is clear that the measured transfer rates are relatively 
iow, reflecting in part the overhead posed by the Symbolics oper- 
ating system. However, the transfer rate between the Symbolics 
and the VAX for a large file was double that to the microVAX for 
the same file, showing that the microVAX also limited the 
transfer rate. These data are preliminary, and tuning of the 
systems may provide improvements. However, they suggest that the 
overall performance of the SADPnet may be strongly constrained by 
the computers at each end of the link. 

End-user functions 


For SADPnet, three major end-user functions dominate the 
design: process-to-process communications services; virtual 

terminal services; and file transfer services. 

The links that will be needed between expert systems are 
examples of process to process (p-p) communications. Figure 1 
shows one possible requirement for links between JSC and LeRC to 
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connect testbeds at each site. When connected, the expert system 
controllers will share information and coordinate actions in a 
manner similar to that needed in a Space Station environment. 



Heavy communications load 
Light communications load 



Heat load 


Figure 1. Possible 90 Demo p-p communications 


Because these systems have little direct interaction, there 
is no apparent need for high data rate between the TEXSYS con- 
troller and the PMAD controller. After initial setup, the aver- 
age data rate will probably not exceed one packet per second. 

Link periods will range from two hours, during the installation 
and integration activities, up to several days for the demonstra- 
tions. Outages during this period must be avoided or the demon- 
stration activity may have to be aborted and rescheduled. 

In addition to the general p-p links, SADP needs to have a 
virtual terminal (VT) service. VT service allows any of a wide 
range of terminals at one site to act as if it were connected to 
equipment at another site. A VT session will need to provide an 
equivalent to 9600 baud service with link periods of a few 
minutes to a few hours. 

Because it is so visible to the end user, VT service will be 
difficult to provide. Outages, failures to connect, or other 
communications failures will interfere directly with the effic- 
iency of project staff. In addition, personnel who use this ser- 
vice on a local area network get close to 100% availability and 
reliability, and will likely use this as the criterion for suc- 
cess when evaluating an SADPnet implementation. 
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The third service required for SADPnet is a reliable file 
transmission capability. Large file transfers will occur infre- 
quently. The distribution of major system builds, for example, 
are expected to occur no more than once per month, on the 
average. These files are expected to be approximately 2-10 
MBytes in size, and data transfer times for these large files 
should be accomplished in no more- than a few hours. 

Small files will be transferred more often. These files, 
less than 1 MByte in size, should be transmitted in a few minutes 
or tens of minutes. The transfer rate implied by the above 
requirements is modest, less than 15 Kbits/sec. 

It is reasonable to expect file transfers to be efficient 
users of the provided bandwidth of SADPnet. For example, large 
files were recently sent between Langley Research Center and Ames 
Research Center over a dedicated 224 Kb/s PSCN line using TCP-IP 
protocols. The measured transfer rate was 219 Kb/s, exactly as 
predicted by the percentage of overhead in the packet. 

Connectivity and Interfaces to Intra-center networks 


Each center involved in SADPnet will need to communicate 
with at least 2 other centers via SADPnet. In fact, the only 
path where a need for connectivity has not yet been established 
is the MSFC-JSC link. 

A possible configuration of the network at JSC for the 88 
demonstration provides an example of the local elements of the 
overall SADP system. Figure 2 shows a simplified diagram of the 
elements of the TEXSYS system, together with other elements of 
the Thermal Test Bed. The configuration at ARC is similar — an 
Ethernet bus with computers and controllers directly attached. 

Simultaneous service 


The SADPnet cannot be effectively used if it is the equiv- 
alent to a large party-line where only one connection can be sup- 
ported at any moment. The number of simultaneous connections to 
be maintained by SADPnet for the 90 demo will be determined by 
further studies, but is expected to be less than ten. 

Protocols 


The SADP communication service will have to support several 
protocols. Digital Equipment Corp.'s Digital Network Architec- 
ture (DNA) and the ARPAnet TCP/IP protocols are currently used. 
As the SADP progresses, it may be found to be appropriate to 
convert to the ISO standard. Therefore, it is prudent to design 
a network that will simultaneously support all three. This is 
not an unreasonable requirement, as both TCP-IP and DNA are 
designed to be co-resident with multiple protocols. 
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Ethernet using DECnet protocols 



Figure 2 -- Possible network configuration for 88 demo 


Reliability, Availability, and Maintainability 

A basic requirement for the SADPnet is that it provide 
reliable service, that it be available when requested, and that 
an maintenance organization is available and competent to repair 
the service when it fails. These requirements are typically 
known as Reliability/Availability/Maintainability, or RAM. 

Error rate is generally the metric used when considering 
reliability. Based upon recent studies of seventeen PSCN links, 
a reasonable expectation for packet error rate is that it will 
not exceed one packet in a thousand. The PSCN goal for packet 
error rate — based upon ATT standards — is that it not exceed 
0.5 packets per hundred. 

Availability is the probability that the service will be 
available for use when needed, and that no outages (as opposed to 
burst errors) will be encountered once the connection is estab- 
lished. An appropriate availability goal is that the system be 
available for use at least as often as telephonic access to the 
same location. This implies that a request for connection to 
another site should be satisfied with an 0.99 probability at an 
0.50 confidence level. 

Finally, the maintainability of the service should approach 
that provided by most long distance digital common carriers. 
Though the PSCN is a new network, the service provided by PSCN 
operations staff is approaching the level needed. 

Expandability 

Expansion of the SADPnet is a distinct possibility. It 
therefore should be designed now to allow this expansion — 
adding sites, services or levels of performance. Expansion 
should be possible without hurting the existing service and 
without unusual cost impact . 
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PSCN RELIABILITY 


Accurate data are available to judge the PSCN performance in 
terms of error rate. These come from an unpublished study 1 of 
NASnet, a communications network using PSCN that ties computers 
at ARC to 17 other sites, including all of the sites associated 
with SADP. These links include dedicated T1 services, switched 
56 Kb/s services staying on the PSCN backbone, switched 56 Kb/s 
service with tail circuits from the backbone, and dedicated 224 
Kb/s lines through the PSCN backbone. All of these links are 
provided through terrestrial, rather than satellite, services. 

Table 2, below, summarizes the NASnet measurements of the 
PSCN error-rate on 15 of the 17 circuits over a 30 day period. 

Two of the 17 sites had no traffic during this period. 

Table 2 - NASnet traffic statistics 


Site 

up time 

MBytes 

MBytes 

% CRC 

Circuit 





sent 

rcvd 

errors 


type 




1 

736.0 

253.3 

155.0 

0.00 

Ded. 

ATT 

T1 



2 

720.5 

5740.2 

1272.4 

0.02 

Ded. 

224 

Kb 

no 

tail 

3 

699.5 

50.2 

10.5 

0.92 

Sw. 

56 

Kb 



4 

517.9 

1965.0 

83.2 

0.18 

Ded. 

224 

Kb 

no 

tail 

5 

445.5 

14.2 

15.2 

0.00 

Sw. 

56 

Kb 

no 

tail 

6 

226.0 

30.1 

18.0 

0.00 

Sw. 

56 

Kb 



7 

90.3 

32.8 

10.5 

0.01 

Sw. 

56 

Kb 



8 

82.8 

21.1 

6.8 

0.02 

Sw. 

56 

Kb 



9 

58.7 

38.2 

13.8 

0.01 

Sw. 

56 

Kb 



10 

44.3 

74.1 

■ 19.3 

0.01 

Sw. 

56 

Kb 



11 

41.5 

13.3 

5.7 

0.05 

Sw . 

56 

Kb 



12 

37.8 

69.3 

56.2 

0.50 

Sw. 

56 

Kb 



13 

34.6 

42.6 

44.2 

0.01 

Sw. 

56 

Kb 



14 

16.7 

12.2 

40.0 

0.02 

Sw. 

56 

Kb 



15 

4.3 

0.0 

0.0 

0.00 

Sw. 

56 

Kb 

no 

tail 

16 

2.8 

0.2 

0.1 

0.58 

Sw. 

56 

Kb 

no 

tail 

17 

0.0 

0.0 

0.0 

0.00 

Sw. 

56 

Kb 



One 

conclusion 

that can 

be drawn 

from this 

study is 

that i 

the 


dedicated and switched 56 Kb/s PSCN lines can provide error rates 
that are acceptably low when measured against SADPnet require- 
ments. Eleven of the fifteen sites demonstrated packet error 
rates less than one in a thousand, and all had error rates less 
than one in a hundred. The PSCN goal for error rate is 1 in 200, 
limited by the commercial carrier offering. 


1 Data here were provided by Judy McWilliams, General 
Electric Corp, from studies covering the 15 week period from May 
24, 1987 through Sep 4, 1987. 
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However, the study reveals some problems in terms of avail- 
ability. The three dedicated line circuits in this network 
should have had 100% availability; only one of these lines 
achieved that goal. 

That line (to Site 1) provides a standard by which the 
others can be judged. It is a dedicated T1 service running over 
ATT lines that had an uptime of 100%. No packet errors were seen 
on this line under moderate to heavy system loads. 

On the other hand, site 2 had over 15 hours of downtime and 
a resultant availability of 98%, while site 4 achieved only 70% 
availability. The level of service was reported to be considered 
'good' by the users at site 2 and 'poor' at site 4. 

SADPNET OPTIONS 


Since the switched and dedicated line services of PSCN can 
provide connectivity with acceptably low error rates, the design 
process now involves establishing a network paradigm, topology, 
and channel speed; then fleshing these out with hardware and 
software options. 

SADPnet Paradigm 

Because the goal of SADPnet is to connect LANs at each site, 
the basic network paradigm proposed is that it be an extended 
Ethernet service, though one that has a lower bandwidth for 
inter-center traffic than that provided intra-center. This para- 
digm permits the use of existing hardware, software, and proto- 
cols, and allows for the addition or removal of computer equip- 
ment at each site without coordination problems. In addition, 
experience with this approach has shown it to be both feasible 
and economical. 

This paradigm involves three major elements, as shown in 
Figure 3. The top element is the communications network provided 
by PSCN lines, whether dedicated or switched. The bottom element 
is the local network, containing the existing and planned 
development and testbed computers. In between is an Ethernet 
bridge device and communications interface. 

The bridge is the critical element in this network. It 
transmits to the other sites only those packets being sent to 
remote systems. This keeps local Ethernet traffic from being 
transmitted through the network, a feature that reduces network 
bandwidth requirements enormously. The bridge makes use of 
configuration information to manage the network traffic, and to 
provide network statistics and security. 
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Figure 3 -- Basic SADPnet paradigm 


Possible Topologies 


The network topology can be a star, a bus, or a series of 
point-to-point links. Figure 4 shows four possibilities. 



Point to point n«two<Tt Dial-up notworh 


Figure 4 - SADP Topology Options 
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The bus, star, and point-to-point options shown in Figure 4 
can meet all SADPnet requirements; the dial-up option can meet 
them under conditions of very light load. Choosing among these 
options will require cost/performance tradeoffs, and a complete 
analysis of these tradeoffs is beyond the scope of this paper. 


CONCLUSIONS 


This study has focussed on communications requirements for 
the SADP 1990 demonstration. The next step is to validate the 
requirements, explore the network options, and select a design. 

A project team, including members from each site, should then be 
formed to implement the network, a schedule and budget for this 
project established, and implementation begun. 

SADPnet will be the first within NASA to be used to connect 
interacting automated controllers, and to do so over long 
distances. The SADPnet has every chance of meeting technical 
requirements, cost constraints, and schedule requirements, if the 
steps noted above are initiated promptly. 
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